The Internet remains a growing public network. Many companies rely on communication over the Internet to facilitate their business endeavors. However, public access also comes along with security risks. To enhance security on the Internet, the Internet Engineering Task Force (IETF) designed a set of protocols known collectively as Internet Protocol Security (“IPSec”). IPSec is designed to provide authentication and encryption for communication over networks, such as the Internet. Network Address Translation (NAT) has also been a large factor in the growth of the Internet, but unfortunately the operation of NAT is at odds with IPSec.
NAT translates between a set of one or more private IP (Internet Protocol) addresses used for local internal network traffic with one or more “public” IP addresses to be chosen dynamically when internal addresses wish to exchange traffic with external machines. A translation table in a NAT gateway allows an organization's Internet traffic to share one (or more) public address(es) that have been assigned to the organization. Outbound packets for new connections cause new NAT translation table entries to be created in the gateway. The NAT translation table is used to perform inverse translation on traffic arriving in the opposite direction (i.e., incoming traffic—from the public Internet).
A client computer on a LAN may have a local IP address that has been assigned statically; however, conventionally, a Dynamic Host Configuration Protocol (DHCP) server entity dynamically assigns a private IP address to a client computer on a LAN. Such a private address is uniquely chosen from a pool of available private IP addresses. The DHCP server process is frequently co-located in the NAT gateway, but it could be hosted in a separate device within the private network. So, for example, an IP packet from a client computer, or other local machine, which is part of a local or private domain (“behind”) with respect to a NAT gateway, comprises IP Source and Destination addresses in the packet's IP header, and comprises Source and Destination Port addresses in the packet's User Datagram Protocol or Transmission Control Protocol (UDP or TCP) header. Conventionally, the packet's IP Source Address field will contain the private IP address that was statically or dynamically assigned to the client computer, while the packet's IP Destination Address field will contain a private IP address, for a packet destined for another machine behind the NAT gateway, or a public IP address, for a packet destined for another machine not behind the NAT gateway, such as remote computer connected to the Internet.
For the latter example, a NAT gateway changes an outbound packet's IP Source Address field from a locally unique private IP address to a public, or globally unique, IP address. The packet's new Source Address, now a public IP Source Address, is conventionally either the IP address of the NAT gateway's external interface or allocated from a pool of available public addresses managed by the NAT gateway.
Furthermore, a NAT gateway may need to translate transport-layer addresses (i.e., TCP or UDP ports) to allow more connections to share the same IP address. In instances where the NAT gateway is using its own public IP address as a public IP address for outbound packets from local machines, external connections will appear to emanate from the NAT gateway computer. In order to prevent two local client machines from communicating with the same Remote IP Address and selecting the same Destination TCP or UDP Port, which would make it impossible for the NAT gateway to determine which client should get return traffic, each connection at the NAT gateway computer is translated so that outbound traffic appears to emanate from a uniquely identifiable IP public address, and TCP or UDP Source Port pair. The chance of such a situation occurring may sound remote, but it is possible, especially as the number of local clients increases, and it is a situation that may be avoided by performing TCP or UDP port translation in addition to IP address translation. Because a NAT gateway stores not only private/public IP address associations but also TCP or UDP port associations for translation and forwarding of incoming traffic, NAT is sometimes referred to as Network Address and Port Translation (NAPT).
IPSec depends in part on a negotiation of parameters governing a connection that requires enhanced security. The collection of parameters, including such exemplary items as authentication and/or encryption session keys, key lifetimes, encryption or authentication algorithms, among other known items, that govern negotiated security parameters between peer stations are known collectively as a Security Association (SA). An SA negotiation is done in accordance with a protocol known as the Internet Security Association and Key Management Protocol (ISAKMP) using the Oakley key determination algorithm. ISAKMP/Oakley is more commonly known as Internet Key Exchange (IKE). One result of an IKE negotiation is a private agreement on randomly chosen session keys to be used for encrypting and decrypting, and/or for digitally signing messages (i.e., IP packets). UDP port 500 is reserved for ISAKMP, IPSec's control protocol.
IPSec-protected IP packets will incorporate at least one of two types of IPSec security protocol headers, according to whether authentication, encryption, or both, has been negotiated in an IKE. To summarize these IPSec security protocol headers for purposes of clarity: an “Authentication Header” (AH) is used when authentication has been negotiated, an “Encapsulating Security Payload” (ESP) header is used when encryption has been negotiated, and an AH encapsulating an ESP header is used when an IP packet contains both AH and ESP headers such as when ESP with AH has been negotiated.
Once an IPSec Security Association has been established, an Internet Protocol header of each IPSec-protected packet specifies the type of security protocol in use, i.e., AH or ESP, including a combination thereof. In IP version 4 (“IPv4”), there is an 8-bit “Protocol” field in an IPv4 header, which indicates the next higher-layer protocol that is logically above the IP layer. In IP version 6 (“IPv6”), there is an 8-bit “Next Header” field that provides similar functionality to the Protocol field in an IPv4 header. In both IPv4 and IPv6, a value of 0x32 means ESP, and 0x33 means AH. The AH and ESP headers both contain a 32-bit field for a numerical value known as a Security Parameters Index (SPI).
If an IP packet has been digitally signed (using AH), certain important parts of the IP header of such an IP packet may not be modified, else an IPSec peer station receiving such an IP packet will not be able to verify that the IP packet's digital signature is correct. But, in the course of a conventional operation, a NAT gateway will change the packet's IP Source Address for outbound (i.e., local-to-remote, or private-to-public) packets, or the packet's destination address for inbound (i.e., Remote-to-Local, or public-to-private) packets. In either direction, NAT transformation of the IP header will impede the IPSec peer station's ability to verify the AH digital signature. For an outbound traffic example, when an intervening NAT gateway or router changes a packet's private IP Source Address to a global, or public, IP address, authentication at a receiving computer will fail since the private IP address is no longer available to the receiver in its verification of the digital signature. Heretofore, IPSec AH was incompatible with NAT owing to necessary changes made to an IP packet during transit through a NAT gateway.
For encrypted but not signed packets (i.e., those IPSec packets that are protected by ESP without AH), transport layer headers are not decipherable to third parties (nor are they at their usual locations in the packet, even if they were decipherable), including a NAT gateway, and thus TCP or UDP port numbers are not available for a NAT gateway to use in the process of outbound and/or inbound translation. Thus, even IPSec ESP alone (i.e., ESP without AH) interferes with basic NAT operation, regardless of the presence of an Authentication Header. By extension, for an IP packet that is protected by both AH and ESP, it's source IP address may not be changed and port numbers are encrypted.
In summary, an AH header, an ESP header, or both may be added to an IP packet. Importantly for NAT, the IP Source Address field of AH-protected packets cannot be changed, because it is part of the input to the digital signature algorithm. Importantly for ESP-protected packets, the IP Source Address may be changed without interfering with the ability of peer stations to decrypt received packets, though Source and Destination Port numbers are encrypted and thus not decipherable to by a NAT gateway. So in the context of ESP, heretofore there was no mechanism to clarify return traffic routing, namely, to determine which private station should receive an ESP-protected packet, as TCP or UDP port numbers are not decipherable by the NAT gateway. Moreover, ESP-protected traffic for a Virtual Private Network (VPN) heretofore limited the number of VPN sessions to a same Remote IP Address or involved non-standard modifications to a VPN client.
Accordingly, it would be desirable and useful to provide an integration of NAT and IPSec that does not add significant overhead and does not require an IP Source or Destination Address and/or TCP or UDP Source or Destination Port translation that is incompatible with IPSec's security algorithms.